作為識別潛在漏洞條件的依據有哪些

以下這些可以作為識別潛在漏洞條件的依據：

• HTTP狀態碼：Web 服務器的請求響應包含一個三位數字的代碼以標識請求的狀態。在 RFC2616-超文本傳輸協議-HTTP/1.1的第十部分可以找到完整的狀態碼列表。狀態碼可以提供確定哪些模糊請求需要進一步研究的線索。例如，一系列 500 錯誤（表示“內部錯誤”的狀態碼）可能意味著前面的請求導致服務器發生錯誤。401錯誤（表示“未授權錯誤”的狀態碼）則意味著被請求的頁面存在，但是受密碼保護。

• Web服務器錯誤消息：Web應用可能會直接在Web頁面內容中顯示錯誤消息。使用正則表達式來解析包含在響應中的HTML可以找到這類消息。

• 中斷連接：如果某個模糊測試輸入導致Web服務器掛起或發生崩潰，后續請求將不能成功地連接到服務器。因此，模糊測試工具應當維護日志文件，記錄管道中斷或是連接失敗事件。當查看日志文件并發現一系列的連接失敗后，就可以直接查看剛好在發生錯誤的日志條目之前的請求，確定故障所在。

• 日志文件：大多數Web服務器可以被配置為記錄多種類型的錯誤。這些日志同樣可以提供發現哪些模糊請求會導致一個可被利用的條件發生的線索。使用日志文件所面臨的難點是無法直接根據日志文件找到導致錯誤的請求。將請求和錯誤日志聯系起來的一個可行方法是，將攻擊計算機和目標計算機的時鐘進行同步，查看請求和日志條目的時間戳，這樣可以縮小需要檢查的范圍，但它仍然不能準確、確定地將某個模糊測試請求關聯到它導致的故障。

• 事件日志：事件日志也不能直接對應到相應的請求，但可以通過時間戳關聯到特定事件，在這一點上它與Web服務器日志類似。微軟的Windows操作系統使用了事件日志，可以通過事件查看器（Event Viewer）應用查看事件日志。

• 調試器：鑒別已處理和未處理異常的最好方法是，在開始模糊測試之前將目標應用連接到調試器。錯誤處理機制可能會掩蓋模糊測試導致的許多明顯的故障表現，但通過調試器通常可以發現這些錯誤。尋找已處理的異常和尋找未處理的異常同樣重要，因為錯誤處理機制會處理某些特定類型的錯誤，如解引用空指針以及格式字符串引發的異常，但如果給定恰當的輸入，它們也可以成為可被利用的漏洞。和上面的異常檢測方法一樣，這里面臨的最大挑戰仍然是確定哪個請求導致異常的產生。在Web應用模糊測試方面調試器有一定的局限性，因為調試器可以發現服務器的異常，卻不能發現應用層的異常。

回答所涉及的環境：聯想天逸510S、Windows 10。